Re: having both release and debug version of openssl on win32?

[Katie Lucas]

On Mon, Nov 07, 2005 at 05:37:59PM +0100, Julien ALLANOS wrote:
> Julien ALLANOS a =E9crit :
> >Hello,
> >
> >I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,=20
> >and other libraries. Thus I have to build them all using the same link=
=20
> >configuration (/MD). However I want to be able to debug my application=
,=20
> >and have both Release and Debug versions of every libraries in the sam=
e=20
> >time on disk. Is there a way to build libeay32D.{lib|dll},=20
> >ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build=20
> >process?
> >
> >Thanks,
>=20
> Actually, I have an application and a DLL. The DLL depends on the=20
> previous libraries. And I just saw the applink.c tip in the FAQ. As I=20
> don't really want to debug OpenSSL, but rather my application and my=20
> DLL, I have included applink.c in my DLL project, compiled it in Debug=20
> mode (/MDd) against a Release (/MD) libeay32, compiled the executable i=
n=20
> Debug mode and ran it. I get the "no OPENSSL_Applink" error again. Any=20
> help please? Thanks.

You need to do some jiggery-pokery to get the Applink table to appear
properly named in the symbol table.

We had to declare it (using Borland) as;

extern "C"
{

__declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
{
...
}
}

The "extern C" stops name mangling happening, the "Pascal" stops an
underscore being prepended to the name. The "__declspec(dllexport)" is
needed to stop the linker going "hey, this isn't mentioned, I'll
remove it".

It's not mentioned otherwise because the Uplink system uses
"GetProcAddress" to provide runtime name resolution instead of a
compile-time dependency.

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Julien ALLANOS]

Katie Lucas a =E9crit :

> On Mon, Nov 07, 2005 at 05:37:59PM +0100, Julien ALLANOS wrote:

>=20

>>Julien ALLANOS a =E9crit :
>>
>>>Hello,
>>>
>>>I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,=20
>>>and other libraries. Thus I have to build them all using the same link=
=20
>>>configuration (/MD). However I want to be able to debug my application=
,=20
>>>and have both Release and Debug versions of every libraries in the sam=
e=20
>>>time on disk. Is there a way to build libeay32D.{lib|dll},=20
>>>ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build=20
>>>process?
>>>
>>>Thanks,
>>

>>Actually, I have an application and a DLL. The DLL depends on the=20
>>previous libraries. And I just saw the applink.c tip in the FAQ. As I=20
>>don't really want to debug OpenSSL, but rather my application and my=20
>>DLL, I have included applink.c in my DLL project, compiled it in Debug=20
>>mode (/MDd) against a Release (/MD) libeay32, compiled the executable i=
n=20
>>Debug mode and ran it. I get the "no OPENSSL_Applink" error again. Any=20
>>help please? Thanks.

>=20
>=20

> You need to do some jiggery-pokery to get the Applink table to appear
> properly named in the symbol table.

>=20

> We had to declare it (using Borland) as;

>=20
> extern "C"
> {
>=20

> __declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
> {
> ...
> }
> }

>=20

> The "extern C" stops name mangling happening, the "Pascal" stops an
> underscore being prepended to the name. The "__declspec(dllexport)" is
> needed to stop the linker going "hey, this isn't mentioned, I'll
> remove it".

>=20

> It's not mentioned otherwise because the Uplink system uses
> "GetProcAddress" to provide runtime name resolution instead of a
> compile-time dependency.

>=20

It still doesn't work. And the xmlsec building process doesn't include=20
applink.c, so I would rather be interested in building a Debug version=20
of OpenSSL, but changing names of libraries to add a "D" (libeay32D,=20
ssleay32D...), to be able to have Release and Debug versions side by side.

For the moment, I have:

1/ set "mk1mf.pl debug" into ms\do_masm.bat

2/ run perl Configure VC-WIN32

3/ run ms\do_masm.bat

4/ replaced:

* SSL=3Dssleay32 by SSL=3Dssleay32D
* SSL=3Dssleay32 by SSL=3Dssleay32D

in ms\ntdll.mak

5/ run nmake.exe /f ms\ntdll.mak

I get libeay32D.{lib|dll} and ssleay32D.{lib|dll}, which looks fine, but=20
actually ssleay32.dll get linked against libeay32.dll, not libeay32D.dll!=
!

Any hint please? Thanks!
--=20
Julien ALLANOS

[Julien ALLANOS]

Julien ALLANOS a =E9crit :
> actually ssleay32.dll get linked against libeay32.dll, not libeay32D.dl=
l!!

Of course I meant ssleay32D.dll.

[Andy Polyakov]

>>Actually, I have an application and a DLL. The DLL depends on the

>>previous libraries. And I just saw the applink.c tip in the FAQ. As I

>>don't really want to debug OpenSSL, but rather my application and my

>>DLL, I have included applink.c in my DLL project, compiled it in Debug

>>mode (/MDd) against a Release (/MD) libeay32, compiled the executable in

>>Debug mode and ran it. I get the "no OPENSSL_Applink" error again. Any

>>help please? Thanks.

>
> You need to do some jiggery-pokery to get the Applink table to appear
> properly named in the symbol table.

... in the [export] symbol table of the *application*. The applink.c
module has to be lunked into *application,* not some other dll, even if
it's dll that links with openssl dll and not application itself.

> We had to declare it (using Borland) as;
>

> extern "C"
> {

>
> __declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
> {
> ...
> }
> }

extern "C" makes perfect sense, but PASCAL? It doesn't make sense...
Documentation references indicate that PASCAL capitalizes name [not to
mention alternative argument passing convention, but it's lesser problem
in this case, because we don't pass any arguments here], which means
that exported symbol should come out incompatible... So how come it
worked? But Borland apparently supports __cdecl, can you verify if it
does the trick?

> The "extern C" stops name mangling happening, the "Pascal" stops an
> underscore being prepended to the name.

But Microsoft C prepends the name with underscore... Well, it's then
stripped off by linker... I always get a bit dizzy in between Win32
compilers...

> It's not mentioned otherwise because the Uplink system uses
> "GetProcAddress" to provide runtime name resolution instead of a
> compile-time dependency.

Correct. And the symbol is looked up in .exe image used to create
current process. A.

[Katie Lucas]

On Tue, Nov 08, 2005 at 06:04:05PM +0100, Andy Polyakov wrote:

> extern "C" makes perfect sense, but PASCAL? It doesn't make sense...
> Documentation references indicate that PASCAL capitalizes name [not to
> mention alternative argument passing convention, but it's lesser problem
> in this case, because we don't pass any arguments here], which means
> that exported symbol should come out incompatible... So how come it
> worked? But Borland apparently supports __cdecl, can you verify if it
> does the trick?

I agree, the docs for BC++ indicate it should affect the name in other
ways, but it did solve the issue of the GetProcAddress not finding the
name.. Sadly I gave up experimenting after this since we couldn't get
the thing to work reliably even given that, and eventually we coerced
a build to happen with BC++6 which works all lovely and nice and
everything "just happens".

> But Microsoft C prepends the name with underscore... Well, it's then
> stripped off by linker... I always get a bit dizzy in between Win32
> compilers...

Ah, I think it's that that's the issue -- the BC++ linker doesn't
(IIRC) strip off the underscore[1]. ISTR something involving adding them while
doing VC++ -> BC++ library conversions. (It's been a while).

[1] I miss UNIX's "nm" SO much while doing this stuff...